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Abstract 

(N . 

^vj , One of the differences among the various approaches to suspension-based tabled evaluation is 

the scheduling strategy. The two most popular strategies are local and batched evaluation. The 
former collects all the solutions to a tabled predicate before making any one of them available 
I— J , outside the tabled computation. The latter returns answers one by one before computing them 

^•^ • all, which in principle is better if only one answer (or a subset of the answers) is desired. Batched 

(/3 I evaluation is closer to SLD evaluation in that it computes solutions lazily as they are demanded, 

O ■ but it may need arbitrarily more memory than local evaluation, which is able to reclaim memory 

sooner. Some programs which in practice can be executed under the local strategy quickly run 
out of memory under batched evaluation. This has led to the general adoption of local evaluation 
at the expense of the more depth-first batched strategy. In this paper we study the reasons for 
the high memory consumption of batched evaluation and propose a new scheduling strategy 
\^ , which we have termed swapping evaluation. Swapping evaluation also returns answers one by 

On ' one before completing a tabled call, but its memory usage can be orders of magnitude less than 

CO ' batched evaluation. An experimental implementation in the XSB system shows that swapping 

1^^. I evaluation is a feasible memory-scalable strategy that need not compromise execution speed. 
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1 Introduction. 



Tabling ffamaki and Sato 19861 IWarren 19921 IChen and Warren 1996) is a strategy for 
5^ \ executing logic programs that remembers subgoal caUs and their ansv^rers to respond 

to future calls. This strategy overcomes several of the limitations of the SLD resolu- 
tion strategy. In particular, it guarantees termination for programs with the bounded 
term size property and can improve efficiency in programs which repeatedly perform 
some computation. These characteristics help make logic programs less dependent on 
the order of clauses and goals in a clause, thereby bringing operational and declarative 
semantics closer together. Tabled evaluation has been successfully applied to deduc- 
tive databases JRamakrishnan and Oilman 1993t , program analysis l lWarren et al. 1988] 
iDawson et al. 199&I . semantic Web reasoning iZouet al. 20051 . model checking JRamakrishna et al. 1997t . 
etc. 

One of the key decisions in the implementation of tabled evaluation is when to re- 
turn new answers to subsequent calls (called consumers), i.e., the scheduling strat- 
egy. Two main scheduling strategies have been studied and applied so far: local and 
batched iFreireetal. 2001t . 
Local scheduling computes all the answers of a generator (the first appearance of 
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a call to a tabled predicate) before returning them outside the generator subtree. It is 
efficient in terms of time and stack usage when all answers are needed. It is also efficient 
when an answer maximizing or minimizing some metric is required, because usually all 
the answers are available when it comes to computing the extremal one. 

Batched evaluation returns answers as soon as they are available. It is efficient for 
finding the first answer (or, in general, some but not all answers) of a tabled predicate 
and for parallelizing tabled evaluations: in parallel local evaluation, consumers outside 
the generator subtree have to wait for the generator to complete, while in batched eval- 
uation these consumers could in principle run in parallel and use answers stored in the 
table while the generator is still computing and adding more answers. Batched evalua- 
tion, however, may need arbitrarily more memory than local evaluation: space can be 
reclaimed when subgoals have been completely evaluated, and local scheduling com- 
pletes goals earlier and so can reclaim space earlier, while batched evaluation normally 
has more subgoals in the process of being computed at any particular point in time 
(and thus not completed) . Memory management is also complicated by its usual stack- 
based nature, and batched evaluation ends up with more unused memory trapped in 
the stacks. We will analyze these factors and propose solutions to improve the mem- 
ory usage of batched evaluation while still keeping its good behavior for first-answer 
scenarios. 

The remainder of the paper is organized as follows: Section[2]gives a brief account of 
the advantages that answer-on-demand tabling can bring. Section |3] gives an overview 
of tabled evaluation and the implementation of the SLG-WAM inXSB. Sections|4]and[5] 
explain why batched evaluation uses more memory than local evaluation and pro- 
pose how to improve it through a new scheduling strategy, swapping evaluation. Sec- 
tion[6]evaluates our solution experimentally and shows that in some cases it uses orders 
of magnitude less memory than batched evaluation without compromising execution 
speed. As there are applications where swapping evaluation is better than local evalua- 
tion and vice-versa, Section lOl suggests how to combine both evaluations in the same 
engine. Finally, Section|7]shows some implementation details. 

2 Motivation. 

We can loosely divide many Prolog applications into two broad categories: in-memory 
deductive database applications where all answers to a query are required, and artificial 
intelligence (AI) search applications where it is required only to determine the existence 
of a solution and perhaps provide an exemplar. Tabled Prolog has been effectively ap- 
plied for the former type, such as model checking and abstract interpretation, but not so 
effectively for the latter, such as planning. This may be traced back to the fact that local 
scheduling is memory efficient for all-answer queries, but batched scheduling, which 
is better for first-answer queries, shows relatively poor memory utilization in the lat- 
ter case. XSB does implement an optimization, called early completion, which is some- 
times able to avoid unnecessary search after a ground query has been found to be true, 
but it is highly dependent on the syntactic form of the rules and often allows unneces- 
sary computation. The swapping evaluation strategy proposed in this paper is a depth- 
first search strategy that has memory performance much closer to local scheduling. In 
fact the order of its search is much closer to Prolog's order than is batched scheduling, 
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thus allowing Prolog programmers' intuitions on efficient search orders to be brought 
to bear while programming in tabled Prolog. We believe swapping evaluation will make 
tabled Prolog a much more powerful tool in tackling applications in AI areas involving 
search. 

3 An Overview of Tabled Evaluation. 

We assume familiarity with the WAM lAit-Kaci 19911 and the general approach to 
implementing suspension-based tabled evaluation, but for completeness we present 
an overview of the main tabling ideas in this section. We will focus on the im- 
plementation approach of the SLG-WAM jSagonas and Swift 1998 as it appears in 



XSB I jSagonas et al. 199^ , the platform on which we have developed our prototype im- 



plementation. 

Suspension-based tabling systems have four new operations beyond normal SLD ex- 
ecution: tabled subgoal call, new answer, answer return, and completion. Tabled subgoal 
call checks if a call is a generator (the first call to the subgoal) or a consumer (a subse- 
quent call). If it is a generator, execution continues resolving against the subgoal call 
clauses. If it is a consumer, the answer return operation is executed and the consumer 
draws answers from an external table, where the generator inserts each answer it finds 
using the new answer operation. 

When no more answers are available for a consumer, its execution suspends and 
freezes the stacks. This is necessary since the generator may generate new answers in 
the future, in which case the consumer must be resumed to process that new answer. 
Suspension is performed by setting freeze registers to point to then-current stack tops. 
No memory older than what the freeze registers point to wiU be reclaimed on backtrack- 
ing, since it may be needed to resume the consumer. Finally, when a generator has found 
all its answers, it executes the completion operation, where relevant memory structures 
are reclaimed and the freeze registers are reset to their original values at the time of the 
generator call. Tables are not reclaimed on backtracking, and therefore do not need to 
be protected. 

The completion operation is complex because a number of generators may be mu- 
tually dependent, thus forming a Strongly Connected Component (SCC jTarjan 1972| ) 
in the graph of subgoal dependencies. As new answers for any generator can result in 
the production of new answers for any other generator of the SCC, we can only com- 
plete all generators in an SCC at once, when a fixpoint has been reached. The SCC is 
represented by the leader node: the youngest generator node which does not depend 
on older generators. A leader node defines the next completion point. 

XSB implements a completion optimization which obtains answers directly from the 
table when a consumer returns answers from a completed tabled subgoal. With this op- 
timization answers are not necessarily returned in the original order. However, when 
answers are returned from an incomplete tabled subgoal, they are returned in the orig- 
inal order using an ordered list of answers. 

Another important operation in the SLG_WAM is consumer environment switching. 
When new answers are available for a suspended consumer, that consumer is resumed 
to continue its suspended execution. This is done by locating the first common ances- 
tor of the current execution point and the consumer to be resumed. Bindings from the 
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?- a(X). 

:- table a/1, b/1. 

a(X) :- b(Y), a(X). 
a(X) :- ... 

b(l). 

b(X) :- large, b(X). 

Fig. 1. Tabled program. 
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Fig. 2. ASCC memory behavior. "P" is a large SLD execu- 
tion. 



current execution point to that ancestor are undone, and bindings from the common 
ancestor until the consumer are reinstalled. 



4 Improving Memory Usage by Precise Completion Detection. 

One of the reasons for the importance of the completion instruction is that it allows 
reclaiming memory from the WAM stacks. Before a generator begins doing clause res- 
olution, it saves the then-current values of the freeze registers. Their values generally 
change during the execution of the generator in order to preserve the execution state 
of new consumers. When the generator completes, the freeze registers are reset to their 
original values and the frozen space is reclaimed. 

4. 1 An Overview of ASCC Memory Behavior. 

Batched evaluation, as implemented in XSB, uses an approximation to detect SCCs 



(termed ASCC Sagonas and Swift 1998 ) in which the completion of some generators 



is postponed to ensure that memory needed by later executions is not incorrectly re- 
claimed. However, this results in keeping some space frozen that could be reclaimed. 
Consider the example code in Figure[T] Figure[2l;A) shows the stack of the generators, in 
which Gb is under Ga at the moment of the b (Y) call. The triplets of the completion stack 
(on the right) are the original identifier of each generator, its deepest dependence|J and 
the values of its freeze registers; note that we are showing only the choicepoint stack, 
and therefore we need just the freeze register for it. Then, Gb finds a solution and a 
consumer (Ca) of Ga appears in the first clause of a/1. Thus, Gb cannot be completed 
before Ga when the ASCC is used to ensure that memory frozen by Ca is not incorrectly 
reclaimed (see Figure lltB)). Gb continues its execution and a consumer Cb of Gb ap- 
pears, which freezes a lot of memory. That memory can be released upon completion 
of Gb, but it is not released using the ASCC (see FigurelUC)) because the leader of Gb is 
Ga, and the completion of Gb is postponed. 



A generator can complete if its deepest dependence is not lower than its own identifier. 
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Fig. 3. sec memory behavior. 

4.2 A Solution: Imposing SCC Memory Behavior. 

The ASCC changes the structure of the SCC to overapproximate the protection of frozen 
memory. In the previous execution, Gb does not depend on Ga, because Ca lies outside 
the scope of Gb. Instead of changing the SCC structure, we propose to let Gb complete 
and release memory up to Ca (the youngest node belonging to a not-yet- completed 
SCC) . We do this by changing the original values of the freeze registers that were stored 
when a generator was created. When a consumer appears, all the generators that appear 
after that consumer's generator have their original freeze register values updated to the 
current freeze register values. Then, the memory frozen by the new consumer will not 
be reclaimed if those generators complete. 

Consider the previous execution using the new approach. When Ca appears, the 
stacks are frozen until cell number 3 (included). The generators which appeared after 
Ga (the generator of the new consumer) update their freeze register values to be 3, but 
the SCC structure is not changed (see Figure IH A)). Then, Cb freezes the stacks (see Fig- 
urelUB)) but since Gb is a leader node, it can complete and the value of the freeze reg- 
isters is updated to be 3. All the memory frozen by Cb is reclaimed (including ancillary 
memory used by Gb such as its ordered list of answers and list of consumers) without 
reclaiming the memory frozen by Ca (see Figure OO). The memory used by Gb is kept 
unreclaimecu. 

5 Swapping Evaluation: the General Idea. 

Both in local and batched evaluation, whenever a new consumer whose generator has 
not been completed appears, execution suspends after consuming all the available an- 
swers and WAM stacks are frozen. Some of these suspensions are inherent to tabled 
evaluation, but some others are not, as we will see in the next section. 

5. 1 External Consumers: More Stack Freezing than Needed. 

We define two kinds of consumers: internal and external. A consumer is inter- 
nal to an SCC when it appears inside the execution subtree of that SCC, and it 



It could, however, be collected by garbage collection. This kind of trapped memory already appears in the 
SLG-WAM and, interestingly, in the marker model for independent and-parallel execution when backtrack- 
ing happens on trapped goals (Hermenegtldo and Nasr 1986) 
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is external otherwise. As a simple example, let us have a program with clauses 
{(:-table a/0), (a :- a), (a)} and the query ?- a, a . The leftmost a in the query is a gen- 
erator, the a in the body of the first clause is an internal consumer, and the rightmost a 
in the query is an external consumer. 

Freezing the stacks associated with internal consumers is necessary for suspension- 
based tabled evaluation because they avoid infinite loops. But external consumers 
(which don't appear in local evaluation) freeze the stacks so they can resume when the 
generator produces additional answers. Note that new external consumers can freeze 
the stacks again in those branches generated by a external consumer suspension. This 
stack freezing happens out of the scope of the tabled evaluation, leading to a sort of 
memory-consuming breadth-first search which may require significant memory as the 
following example shows: 

?- t(X), p, t(Y), fail. p :- largel. 

:- table t/1. p :- Iarge2. 

t(l). 

t(2). p :- largeN. 

t(l) is found and then the first clause of p/0 is executed. Then t(Y), which is the 
first consumer, consumes t( 1 ) and execution suspends after freezing the stacks because 
there are currently no more available answers for the consumer to return. Execution 
backtracks to the second clause of p/0 but the memory used by the execution of the first 
clause of p/0 has not been reclaimed. The same behavior will happen with the second 
consumer of t(X) after the second clause of p/0 succeeds. At the end of the program, 
N large computations corresponding to each of the clauses of p/0 are frozen, in a fash- 
ion similar to a breadth-first search evaluation. In the next section we will see how this 
behavior can be avoided. 

5.2 Swapping Evaluation: External Consumers No Longer Suspend. 

An external consumer suspends when it does not have more available answers, and it 
waits for its generator to (eventually) produce more answers. We propose a different ap- 
proach. When an external consumer needs more answers, it is transformed into a gen- 
erator to produce them. Symmetrically, its generator is transformed into a consumer, 
because answers wiU be computed by the new generator. We termed this new schedul- 
ing strategy swapping evaluation because an external consumer and its generator are 
swapped. The swapping operation can be seen as a change in the backtracking order 
since we backtrack over the generator before backtracking over the top of the stacks. 

Consider the previous example using swapping evaluation. When the consumer t(Y) 
needs more answers, it is transformed into a generator to find the second answer t(2). 
Note that it does not recompute the first solution; it instead continues where the genera- 
tor left the computation. Then, execution fails (due to the call to fa i I/O in the query) and 
the swapped generator completes. The first clause of p/0 is backtracked over, but now 
the space it used can be reclaimed. A new consumer appears after the second clause of 
p/0 succeeds which consumes both answers (using the completion optimization) be- 
fore fail/0 is reached. Execution backtracks over the remaining clauses of p/0 untU it 
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fails. Finally, the original generator consumes the second answer t(2). The rest of the 
execution continues as expected, with the former generator, now consumer, t(X) con- 
suming saved answers. The result is that at most one clause of p/0 is kept in the stacks 
at a time, as in depth-first evaluation. 

This is the most basic example of swapping evaluation, but the swapping operation 
is complex due to swapping control, precise completion detection, and the reordering 
of the stacks to change the backtracking order. Section [7] gives implementation details 
of swapping evaluation. 



This scheduling strategy was prefigured in Sagonas and Stuckey 2004 , where the au- 
thors suggested it as a way to recover SLD-like execution to support cuts. As they show, 
local and batched evaluation do not follow the order of SLD resolution even if there are 
no internal consumers, but swapping evaluation has an interesting property: "if SLD res- 
olution finishes, swapping evaluation keeps the clause resolution order of SLD, but some 
(redundant) branches are pruned." 

We independently rediscovered this strategy by analyzing where memory usage in 
batched scheduling was excessive and deriving methods to improve that. Our original 
contribution is the design of the algorithms and data structures, their efficient imple- 
mentation, and their performance evaluation in XSB. Our performance analysis sup- 
ports the effectiveness of the solution. 

6 Experimental Performance Evaluation. 

We have implemented the techniques proposed in this paper in the XSB sys- 



tem Sagonas et al. 1993 . AU of the timings and measurements have been made with 
XSB Version 3.2, disabling the garbage collector: we wanted to study the effects in time 
and memory consumption of the different evaluation strategies, without additional 
"agents" which could add additional noise. We used gcc 4.1.1 to compile the systems 
and we executed them on a machine with Ubuntu 8.04, kernel 2.6.25, and an 1.6GHz 
Intel Core 2 Duo processor. Execution times are shown in ms. and memory usage in 
bytes. 

The benchmarks, which we will briefly explain here, are available from 
http://clip.dia.fi.upm.es/~pchico/tabling/. tcl, tcr, and ten are transi- 
tive closures on a graph with left, right, and double recursions, respectively, sg is the 
well-known same generation program, numbers takes a list of numbers and a target 
number N, and tries to find an arithmetical expression that evaluates to N using 
operations from a fixed set and all the given numbers. It uses both guided and blind 
search in a potentially huge and irregular space, ultimately driven by number theory. 
atr2 is a compiled version of a probabilistic parser of lapanese by Shigeru Abe, Taisuke 
Sato and Neng-Fa Zhou (13000+ lines), and pg, disj, kalah, gabriel, cs_o, cs r and peep 
are program analyzers created by automatically specializing the original programs w.r.t. 
the generic analyzers iCodish et al. 19981 , and whose sizes range from 600+ to 1500 
lines. 

6.1 First-Answer Queries 

For queries requiring only one solution (see Section |2), swapping/batched evaluation 
can be significantly faster and use less memory (both in the stacks and in the call/an- 
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Table 1. Time and memory comparison of local and swapping evaluations for first- 
answer queries. 

swer table) than local evaluation. Table [T] shows the results, in time and memory, of 
several such programs, under local and swapping evaluation. Batched evaluation is 
not shown because it behaves quite similarly to swapping evaluation in these cases. 
The first four benchmarks look for the first answer of the query presented in the ta- 
ble. atr2 ground parses a (ground) Japanese sentence of twelve tokens. atr2 Ivar and 
atr2 2var parse the same sentence but with the last token and the last and first token, 
respectively, being free variables, which naturally leads to an increase of the size of the 
search space, n u m bers is an example of the kind of program that merely looks for a wit- 
ness for the existence of a solution. In numbersX, X represents the size of the set of 
numbers. 

These results give a strong motivation for using answer- on- demand tabling, as the 
behavior in time and memory of these benchmarks is significantly better under swap- 
ping/batched evaluation than under local evaluation. Notice, specially, the exponen- 
tially bad behavior of numbers when local evaluation is used, while swapping/batched 
evaluation remains linear. 



6.2 All-Solution Queries. 

We have also analyzed a set of well-known programs which are queried to generate all 
the solutions. Note that, following the classification in Section|2] these benchmarks ex- 
emplify the worst case, where local evaluation, naturally devised to generate all the so- 
lutions to a query, performs in general better that swapping evaluation. Therefore they 
are not representative of an average behavior. 

Their memory and time behavior appear, respectively, in Tables |2] and |3l In both we 
show data for local evaluation, original batched evaluation, batched evaluation with 
precise completion, and swapping evaluation (which uses precise completion), plus a 
normalized comparison between swapping and local evaluation. We include both ver- 
sions of batched evaluation to determine whether the differences come from a more 
precise SCC at completion or from using swapping evaluation. 

We divide the benchmarks into three classes, according to their structure. Bench- 
marks from tcl to atr2 are highly tabling intensive. They do not show big differences 
when using the different tabling evaluations because they generate few SCCs. We might 
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Table 2. Memory comparison for all-solution queries. 
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Table 3. Time comparison for all-solution queries. 



in any case conclude that there is a slight overhead due to the precise completion or/ and 
the more involved swapping control. On the other hand, they in general favor swapping 
evaluation memory-wise. 

Benchmarks pg to peep call all the predicates in the analyzers with free variables as ar- 
guments. Every predicate is called from a different clause and after the call finishes faU- 
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ure is forced to generate all the solutions and to backtrack to the next clause. Solutions 
are kept in the table space and can be reused between calls, as benchmark predicates 
call each other internally. Forcing failure simulates a sort of local scheduling, even if 
the engine supports swapping or batched evaluation. For this reason, local performs al- 
ways better than swapping (but within reasonable limits), and batched performs worse 
than swapping, but not with a huge difference. Precise completion brings advantages in 
some benchmarks. 

The queries in the previous paragraph do not represent a common case where there 
are few simultaneous dependencies between producers and consumers. Therefore, we 
have used a new category of queries where the program code is the same as in the previ- 
ous group, but queries to the predicates in the analyzers are arranged in a conjunction, 
resulting in a much more complex set of interdependences (again, due to predicates in- 
ternally calling each other). Generating all the solutions is, as before, forced by a fail/0 
call at the end of the conjunction. 

In this category, swapping evaluation performs somewhat worse than local evalua- 
tion both in memory and (with some exception) in time behavior^ due to the need to 
keep alive the environment stacks of the generators in order to resume search for more 
solutions. However, unlike batched evaluation (which is not even able to finish some of 
the benchmarks), swapping evaluation maintains an acceptable memory behavior. 

As a conclusion, answer-on-demand tabling has been found to be advantageous 
when only some answers are required. However, batched evaluation (the classical 
answer-on-demand strategy) was found to have a very bad memory behavior in cases 
where complex dependencies appear among tabled calls. This problem led to the use 
of local evaluation for all applications (with the lack of efficiency in some cases), but 
we think that our measurements indicate that swapping evaluation is a viable alter- 
native for answer-on-demand applications because it does not have the bad-memory- 
behavior of batched evaluation. 

6.3 Combining Local and Swapping Evaluation. 

The previous section exhibits applications where swapping evaluation performs much 
better than local evaluation (and vice-versa, within reasonable limits). While it could 
be possible to select the adequate engine for every application, for simplicity, ease of 
maintenance, and benefit of the final user, it would be nice to have the tabling engine 
implement only one strategy. We show that this is feasible by demonstrating how local 
evaluation can be effectively emulated by swapping evaluation. Assume that t(X) is a 
tabled predicate in a swapping evaluation engine. It is possible to generate automati- 
cally a wrapper which evaluates t(X) using local scheduling by: 

1. Renaming the header of the clause(s) defining t/1 to be t orig/1. 

2. Adding the following wrapper code: 



This is because swapping evaluation imposes some swapping control, some new data structure manage- 
ment, and mainly an execution stack reordering which leads to a non-negligible overhead. In any case, the 
differences are not very significant, and there are optimizations still available if execution speed proves to 
be a problem (see Section!?]. 
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t(X) :- callisconsumer(torig(X)), !, torig(X). 
t(X) :- (t_orig(X), fail; t_orig(X)). 

If the call to t(X) is a consumer (determined using a builtin available in the tabling 
engine), we consume from t orig(X), and we cut the second clause of t(X). Otherwise 
we force the generation of all the answers for t orig(X) and then we consume themcl 

Experimentally, this simple simulation performs around 10% worse than local evalu- 
ation in memory and time when executing very intensive tabling programs. Note in this 
case the relatively costly swapping operation is never invoked, since there are no exter- 
nal consumers. Therefore the overhead comes from other sources (e.g., the check/insert 
operations in the global table are executed three times for every generator call: one for 
the call is consumer/1 call, and two for the t orig/1 calls of the second clause), and a 
lower-level implementation should improve both memory and time behavior. 

In return, this transformation makes it possible to have, in the same system and with 
the same engine, a predicate-level decision on whether to evaluate under a local or 
a swapping policy, and use the appropriate strategy in each case. A similar consider- 
ation leads to the combination of batched and local evaluation at the subgoal level 
in JRicardo Rocha and Fernando M. A. Silva and Vitor Santos Costa 20051 . However, in 
their work, batched evaluation, with its disadvantages, is still used as the alternative to 
local evaluation, and the way in which it is achieved is much more complex, involving 
lower-level changes to the engine. 

7 Swapping Evaluation Implementation Details. 

We now describe, at a somewhat high level, some implementation details which provide 
an idea of the complexity inherent to the implementation of swapping evaluation. 

Generator Dependency Tree (GDT): we use an XSB register named ptcp (from parent 
tabled choicepoint) which points to the nearest generator under which we are execut- 
ing, and which is stored in each consumer choice point. The ptcp fields of the genera- 
tor choice points make up the GDT representing the creation order and dependencies 
among generator caUs. 

Leader Detection: we have added a new field to every generator choice point which 
keeps track of the leader of each generator (NULL if the generator is a leader itself), 
which is used to accurately reconstruct the SCC. When a new consumer C appears 
whose leader is L^, the generators in the current GDT branch update their leader field 
to be Lq, until we find a generator whose leader is already L^. 

External Consumers Detection: a key to implement swapping evaluation is determin- 
ing whether a consumer is external or internal. To do that, we have defined a new field 
in all the generator choice points (the executing field) which points to a free heap vari- 
able. When the new answer operation is executed, that variable is unified with some 
arbitrary value. Then, whenever a consumer appears, if the executing field of its leader 



Note that a similar transformation to make local evaluation behave as batched or swapping does not seem 
to be possible. 
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generator points to a free variable the consumer is internal and if that variable is uni- 
fied, the consumer is external. Note that that binding is undone if we continue with the 
leader generator execution on backtracking, as we need. 

Creating Generators with Private Variables: since generators can be swapped with ex- 
ternal consumers, and the execution segments of each generator can be moved to the 
top of the stack, the tabled subgoal call operation makes a private fresh copy of the gen- 
erator variables. Then, all the bindings of the generator call will be private to its execu- 
tion, and those new variables cannot be bound from outside the scope of the generator 
execution. Consequently, the execution subtree of the generator can be moved to the 
top of the stacks in the same state as it was left. 

An alternative possibility would be to untrail all bindings done between the last an- 
swer of the generator and the external consumer call in order to recover the original 
generator state each time an external consumer (which was swapped by the genera- 
tor) continues making clause resolution to find new answers. We have chosen to make a 
private copy of generator variables because it does not require a significant use of mem- 
ory (between 2.5% and 0.1% in the benchmarks we have executed) and it simplifies our 
implementation. In terms of speed, we cannot make strong conclusions because the 
untrailing alternative is not implemented, but we are quite confident that their perfor- 
mance would be very similar. 

Thus, in our implementation, each generator has two substitution factors: one for the 
original generator call (to consume answers) and another one for the answer bindings 
of private variables (to insert them in the table). As a drawback, we lose the binding 
propagation of batched evaluation which makes it faster than local evaluation in some 
benchmarks. On the other hand, swapping evaluation performs less trail management 
(because external consumers do not switch their environments) than batched evalu- 
ation, and, also, more consumers can take advantage of the completion optimization 
because some external consumers will find their table entry completed. 

More Functionality in ffee New Answer Operation: Pointers to the tops of the trail and 
choice point stack are saved by the new answer operation when a generator finds a 
non-duplicate answer. Two new fields of the generator choice points, answer cp and 
answer trreg, remember those values. These pointers will be used to determine which 
parts of the execution tree must be moved when the swapping operation is performed 
to continue the execution from where it was left by the generator. 

The Swapping Operation: we term OldGen the choice point of the generator and 
NewGen the choice point of the external consumer to be swapped. First, OldGen is in- 
serted into its corresponding consumer list (the one belonging to the generator pointed 
to by the ptcp register of OldGen) and NewGen is erased from the consumer list it be- 
longs to. Then, the fields of the choice points are updated, such as the program counter, 
the substitution factor of the private copy of variables, the leader of the new genera- 
tor (NULL), the last consumed answer of OldGen (which is the last one found) and the 
executing field of the new generator. The following code summarizes this operation: 

PC(NewGen) = PC(OldGen); 

PC(OldGen) = answerreturninst; 

PrivateSubstitutionFactor(NewGen) = PrivateSubstitutionFactor(OldGen); 
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Leacler(NewGen) = NULL; 

LastConsumeAnswer(OldGen) = LastAnswerFound(NewGen); 

isExecuting(NewGen) = YES; 

If OldGen found an answer before leaving its execution scope, we need to move to 
the top the segment of the choice point stack which belongs to its clause resolution. 
In other words, we move to the top all the choice points between the point where the 
last answer of OldGen was found (pointed to by answer cp) and OldGen. To do that, 
OldGen will point to the current top of the choice point stack and the choice point fol- 
lowing answer cp will point to OldGen. This is implemented by scanning the choice- 
points from answer cp looking for a choice point which points to OldGen; that choice 
point is made to point to NewGen|f| The same reordering is done with the trailj and the 
local stack (indeed, the program counter of the last local stack frame is also updated to 
point to the continuation of NewGen). 

The next step is to reorder stacks from NewGen to the point where the last answer of 
the generator was found. In this case, reordering the local stack is not needed, and the 
choice point which points to answer cp is updated to point to OldGen. The final result 
is that we have moved the execution subtree of OldGen to the top of the stack. 

This stack reordering is also done for all consumers under the execution of OldGen, 
because they can belong to different execution paths|3 Originally, we should traverse all 
the generators in the same SCC OldGen belongs to looking for consumers which appear 
under the execution of OldGen by checking if OldGen appears in their ptcp chain. To 
make this checking more efficient, consumers are stored in the list of consumers of the 
generator pointed to by their ptcp field (which is the nearest generator under they are 
executing) , instead of in the list of consumers of their generator|j 

The final step is to reorder the completion stack and update the freeze registers. 
The portion of the SCC which OldGen belongs to and which is under the execution of 
OldGen, has to be moved to the top of the completion stack (because their correspond- 
ing stacks have been moved to the top) . The freeze register values of these generators are 
updated to protect the memory space of NewGen from backtracking. This is because, 
as the physical and logical order are different, after backtracking over a choice point 
physically younger than NewGen, the associated memory to NewGen would be wrongly 
reclaimed. Indeed, the oldest generator among the generators younger than OldGer|j 
which does not belong to that SCC (called G) receives the original freeze register values 



^ This traversal can be avoided by inserting a marker choice point al^er OldGen and updating its pointer to 
its previous choice point. 

° That means that trail cells are not any longer kept in relative order, and the way environment switching lo- 
cates the first common ancestor of two consumers being switched has to be changed. The new algorithm 
traverses the trail of each of the consumers alternatively, marking cells as they are traversed. The first com- 
mon ancestor is found when an already- marked cell appears. 

This step is not needed should the marker choicepoint optimization be done, as all the consumers would 
be linked to that marker. 

° This change does not affect the rest of the tabling implementation and it should (heuristically) be more 
efficient than the original approach, because switching between consumers will be more likely to select 
those which are closer in the execution tree, thereby reducing the amount of work invested in untrail/redo 
operations. 
The completion stacks gives us the age of the generators. 
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?- a(X), inter, b(Y). 

:- table a/1, b/1. 

a(X) :- a(X). 
a(X) :- codel, 

b(X), 

code2. 

b(X) :- code3, 

a(X), 

code4. 
b(X) :- code5, 

X = 1. 

Fig. 4. Non-trivial see- 
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Fig. 6. And-Or tree execution. 

of OldGen. This is because when G appears, the freeze registers are protecting memory 
of the sec which OldGen belongs to. But that SCC was moved to the top of the stacks, 
and the segment from the memory protected by the original freeze register values of 
G to the memory protected by the freeze registers of OldGen can be reclaimed when G 
completes. 

A Sample Execution We consider a non-trivial swapping evaluation scenario using the 
code in Figure E) The first operation is the tabled subgoal call of a(X) where private 
variables (marked with primes in Figure [6) of the original call are created to facilitate 
moving generator executions. Then, an internal consumer of Ga, Cai, appears and sus- 
pends. When the second generator, Gb, creates its completion stack frame, the freeze 
register value is 2 (see Figure OA)). A new internal consumer of Ga, Ca2i appears and 
suspends, setting the freeze registers to 6. As swapping evaluation needs a precise SCC 
(Section!!), Gb also updates its original freeze register values. Later, Gb finds its first an- 
swer using its second clause. This answer is propagated to the generator and Ga finds 
its first answer (FigureOA) shows answer_cp of each generator). 
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After the execution of inter, there is an external consumer b(Y) of Gb. When it con- 
sumes all the available answers, a swapping operation is performed. Using the limits 
saved by the new answer operation, the dotted rectangle in Figure[6l;A) is moved under 
b(Y) as shown in Figure[6l;B). To do that, we update the pointers to the previous choice 
point of codeS and code2 and the current choice point is code5, as shown in Figure[5tB). 
A similar reordering is done with trail cells and local stack frames. The new generator 
Gb saves the current values of the freeze registers and the freeze registers are updated to 
be 10, to protect the memory of Gb. 

The execution continues as expected until Gb tries to complete. Note that the swap- 
ping operation has transformed Ca2. which was an internal consumer, into an external 
consumer. Consequently, before checking for completion, all the consumers under the 
execution of Gb are checked in case they have become external consumers. We can eas- 
ily access them because, as explained before, consumers are saved in the consumer list 
of the generator pointed to by their ptcp. 

Since Ca2 is now an external consumer, the swapping operation is performed to move 
the execution subtree in the dashed rectangle in Figure |6tB) under Ca2, as shown in 
Figure IHtC) . The reordered choice points are shown in Figure |5tC) . As a consequence, 
generators change their order in the completion stack. The new generator of Ga saves 
the value of the freeze registers and G b takes their values from the previous values of G a 
to reclaim all the memory upon completion of Gb. 

8 Conclusions. 

We have presented swapping evaluation, a new strategy which retains the advantages of 
batched evaluation such as first-answer efficiency but which is memory- scalable with- 
out compromising execution speed. We have implemented swapping evaluation in XSB 
and experimentally tested it in a series of benchmarks, with good memory and speed 
results. 

The motivation behind this new evaluation strategy is to widen the applicability of 
tabled Prolog from DB-like problems to other AI applications, including e.g. search, 
where not all the solutions for a given problem are required. 

Finally, we believe that it would be advantageous to be able to combine the advan- 
tages of local and swapping tabled evaluation in a single system. We have proposed a 
mechanism to easily simulate local evaluation using swapping evaluation, which makes 
it possible to define which evaluation to use at the predicate level. 
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